History-based tracking of user preference settings

ABSTRACT

A process is disclosed for using the existing Universal Resource Identifier (URI) history feature of browsers to maintain user preference settings, or other state information, used by one or more web sites or other systems. In one embodiment, when a user makes a particular preference selection on a web site, the user&#39;s selection is recorded in the browser&#39;s URI history by causing the browser to access a URI (or a set of URIs) representing the particular selection. The same or a different web site may subsequently test the browser&#39;s URI history for this particular URI by including appropriate JavaScript or other executable code in a page requested by the browser. Depending upon the outcome of this test, the web site and/or the page&#39;s executable code may take an appropriate action or inaction consistent with the preference selection.

BACKGROUND

1. Technical Field

The present disclosure generally relates to the maintenance of userstate and historical data, such as (without limitation) web identity,personal information, privacy preferences, opt-out choices, and prioruser actions and behavior, using a browser program.

2. Description of the Related Art

HTTP cookies are a commonly used by web server systems to store userattribute data on user computing devices. When a user requests a webpage, the user's browser sends the previously stored cookie or cookiespertaining to the requested page with the page request. The web serversystem typically uses the received cookie data to personalize therequested page, and/or to track the user's browsing behavior.

To protect user information, browsers are designed to transmit onlythose cookies that correspond to the domain of the requested page orother object. Thus, a cookie set by a web server in one Internet domainordinarily will not be transmitted to a web server in another Internetdomain. In some cases, a web page of a site may include a reference thatallows a third party site to set a cookie on the computing devices ofusers who access the page. Such third-party cookies are used extensivelyin the online advertising and analytics industries to identify behaviorassociated with a pseudonymous user identification code, allowing thesecompanies to associate multiple behaviors across a myriad of sites witha single pseudonymous identity.

It has also become common practice for a site that engages in behavioraltracking to offer users the opportunity to not participate, or “opt-out”of the tracking. The users' opt-out preferences are commonly stored onthe user computing devices as cookies. One problem with this approach isthat it is not well suited for enabling a user to make a single opt-outor other preference selection that applies to multiple web sites acrossmultiple domains. Another problem is that privacy management andsecurity tools commonly delete the cookies that represent the users'opt-out and other preference selections.

There is thus a need for an improved system and method for storing userpreference data and/or other state data.

SUMMARY OF THE DISCLOSURE

A system, method, and computer program product are provided for usingthe existing Universal Resource Identifier (URI) history feature ofbrowsers to maintain state information, such as user preferenceselections, used by one or more web sites or other systems. For example,in one embodiment, when a user makes a particular preference selectionon a web site, the user's selection is recorded in the browser's URIhistory by causing the browser to access a URI (or a set of URIs)representing the particular selection. The same or a different web sitemay subsequently test the browser's URI history for this particular URIby including appropriate JavaScript or other executable code in a pagerequested by the browser. Depending upon the outcome of this test, theweb site and/or the page's executable code may take an appropriateaction or inaction consistent with the preference selection. Thepreference selection may, for example, represent a user's request not tobe tracked, and/or may represent a user's preference for a particulartype of content.

In contrast to cookie-based approaches, this URI-history based approachenables the user preference settings to be shared across multipleInternet domains. For example, web site may present an option thatenables a user to perform a single opt-in or opt-out action that appliesto many different web sites and business entities. The method may,however, be used in combination with cookies to provide a more robustmechanism for maintaining user preference data. The disclosed approachmay also be used in combination with the methods disclosed incommonly-owned U.S. patent application Ser. No. 11/580,023, filed Nov.13, 2006, hereby incorporated by reference in its entirety, in which abrowser cache is used to store user state data.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated in the accompanyingdrawings:

FIG. 1 is a schematic block diagram of a demonstrative architecture of asystem in accordance with some embodiments of the invention;

FIG. 2 is a browser interaction diagram illustrating information flowbetween a browser and service providers in accordance with someembodiments of the invention; and

FIG. 3 is a flowchart illustrating an algorithm for checking stateinformation stored in browser history in accordance with someembodiments of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of specificembodiments of the present invention. However, it will be understood bythose skilled in the art that the present invention may be practicedwithout these specific details. Thus, nothing in this detaileddescription is intended to imply that any particular feature,characteristic, or component of the disclosed system is essential to theinvention. The invention is defined only by the claims. In otherinstances, well-known methods, procedures, and components have not beendescribed in detail so as not to obscure the present invention.

1. OVERVIEW

A method and system are disclosed that enables a web site to record auser's preference selection and/or other state information in a URIhistory maintained by the user's browser. The same web site and/or adifferent web site (which may operate in a different Internet domain)may subsequently test the URI history to determine whether theparticular preference selection has been made.

Broadly speaking, some embodiments of the system cause loadable orexecutable web code to be included in responses to user's browsers,wherein the web code uses the browser's URI history to determine theuser's privacy or other settings. The same system may, for example, havepreviously caused the user's preferred privacy settings to be storedinto the user's browser's URI history. The system may subsequently takeaction upon the information located in the URI history, where suchaction may include causing the user to receive differentiated content,causing more or less information about the user to be retained on theserver, performance of additional processing on the web server or theuser's computing device, and so forth. No modifications to existingbrowsers are required, and no additional software needs to be installedon the user's computing device.

The typical browser URI history has several features which make itparticularly well-suited to storing information regarding a user'spreferred privacy options. First, typical browsers do not allowunrestricted access to URI histories. So, for example, a section ofweb-page-based JavaScript executing on a user's computer typically willbe afforded a set of privileges sufficient only to test for theexistence of a specific, known URI entry in the URI history. TheJavaScript will not have sufficient privileges to read all entries,search entries, create entries, or delete entries. In other words, asection of JavaScript may be able to ask “Does URI foo.com/bar/baz.htmlexist in the history, yes or no?” but will not be able to ask for a listof entries in the history. These access restrictions, which areimplemented within most or all commercially available browsers such asMicrosoft Internet Explorer and Mozilla Firefox, make the URI historyfeature attractive for storing information regarding a user's privacypreferences. As a program (such as JavaScript) has to know the exact URIto check for in the history, malicious programs are largely precludedfrom “going fishing” in the URI history to mine users' preferences.Unless the malicious programs know the exact URI to check for, they willbe unable to access privacy settings stored in the history.

Secondly, and as opposed to cookie storage mechanisms, browserstypically allow cross-site and cross-domain checking of URI historyentries. So, for example, a section of JavaScript downloaded fromalpha.foo.com/one/two may be able to check for the existence of each ofthe following URIs in the history: alpha.foo.com/three/four,beta.foo.com/five, and bar.com/six. In contrast, cookies set by thedomain bar.com are typically unavailable for access by JavaScriptexecuting off a web-page located at foo.com. Such cross-domain access isparticularly useful when coupled with a system for sharing privacyinformation, because the privacy information may be set by code at onedomain (e.g. opt-out-of-everything.com) and read by code on multipledifferent domains (e.g., merchantl.com,searchengine2.com).

For example, a trusted entity could operate a web site (e.g.,www.preferences.org) that enables users to select between variousprivacy-related and personalization-related options. This web site couldrespond to the user's selection by causing a corresponding“standardized” URI to be written the URI history of the user's browser(as described below). Web sites operated by other entities in otherdomains could then check for this and other standard URIs, and couldserve content that corresponds to the user's settings. Differentstandard URIs could be provided for different global settings orpreferences (e.g., “no tracking,” “anonymous tracking only,” “notracking of search query submissions,” “do not use my purchase historyto display product recommendations,” “display my name when I amrecognized,” etc.).

Thirdly, probably because web code objects are typically granted onlylimited access to URI histories, users may be less likely to clear theirURI histories than they are to clear their cookies, cache, or localstorage. Automated security programs, designed to remove personalinformation from a user's machine, may be less likely to clear URIhistories for a similar reason. Depending upon the access patterns ofthe user, URI history entries may also have a longer effective lifetimethan that afforded to caches or cookies. As such, URI histories are anexcellent location to store persistent data regarding a user's preferredprivacy options.

A system which uses URI histories to store state information may also beuseful for synchronizing two or more redundant storage locations,wherein loss or damage of user attribute data may be restored fromredundant storage based on an algorithm, thereby preserving the dataintegrity. Example alternate locations for storage include, withoutlimitation, browser cookies, browser cache, Flash Shared Objects store,storage allocated to Java applets, and other storage media available tothe browser, such as random-access memory. The management of suchstorage locations may occur in spite of manual or automatic clearing ofHTTP cookies, HTTP cache, URI history or other storage locations by auser or a computer software tool, such as (without limitation) thoseproviding security and/or privacy functions related to Internetbrowsing, so long as a single storage location remains. Such alternativesources may be algorithmically maintained, for example, wherein theauthoritative storage locations used to synchronize user attribute datamay be based on criteria, such as, for example, persistency of cookies,and/or Internet cache vitality. Expiration or absence of a cookie, forexample, may trigger resynchronization of the user attribute dataagainst the relevant URI history entries, wherein user attribute datawithin the storage location may be compared to each other, such that adetermination may be made as to which data location if any containsup-to-date user attribute data, and therefore, may be consideredauthoritative.

One embodiment of the present invention comprises a system and methodfor preserving the identity, personal information, and/or opt-in andopt-out choices of a user. One generally accepted opt-out choice is amethod of requiring a targeted user to explicitly respond to asolicitation in order to keep from receiving some service or “widget,”usually associated with marketing. In this embodiment, the identity andopt-out choice may be simply pieces of information to be stored andretrieved from the browser or other storage locations available to thebrowser or browser plug-ins at the appropriate time. Further to thisembodiment, if one storage location loses user attribute data, such asan opt-out choice, an alternative storage location may provide a sourceof user attribute data to re-synchronize the lost data; therebymaintaining the integrity of each storage location and user attributedata therein. The storage and retrieval of arbitrary data follows fromthe particular embodiment.

Browsers may maintain histories, repositories, or other stores ofinformation in addition to a URI history. It is contemplated that suchapplications may provide methods of accessing these histories orrepositories similar to those provided by web browsers implementing URIhistories as described herein. As such, these histories and repositoriesmay be used to store state information using mechanisms similar to thosedisclosed herein.

For example, browsers may also use and/or implement protocols other thanHTTP, such as NNTP, RSS, Gopher, etc. These protocols may lendthemselves to additional (or alternative) use of repositories. Moreover,browser plugins, such as Flash or Silverlight, may perform communicationor transmission outside of an established HTTP connection. A browserexecuting such a plugin may maintain a separate history or repository,potentially distinct from the URI history, for resources requested orused by the plugin. The browser or plugin may provide access to such ahistory on conditions similar to those discussed above for URIhistories. In browsers that implement multiple protocols, historyinformation created under one protocol may be read or used under anotherprotocol.

It is contemplated that such repositories may be designed to track ormaintain information distinct from that of typical browser URIhistories, viz., tracking URIs accessed through HTTP. For example, abrowser may maintain a history of terms that a user has searched forusing a browser toolbox. Such repositories may be used to infer userchoice or behavior, and thereby may be used to perform additionalprocessing. In the case of a browser history of search terms, a certainprivacy choice may be inferred from the existence of such terms as “howto opt-in to retailer.com” or “retailer.com privacy policy.” Those ofskill in the art will recognize that these examples may be generalizedto repositories that store, in general, information indicative of userhistory, behavior, and choices.

2. SYSTEM COMPONENTS

FIG. 1 illustrates a schematic block diagram of a demonstrativearchitecture of a system in accordance with some embodiments of theinvention. Web sites 101, 102, and 103 are connected via the Internet100 to each other and to at least one user computing device or machine120 such as a personal computer, personal digital assistant, mobilephone, or television set-top box.

A user's computing device 120 typically includes a browser 121. As usedherein, the term “user computing device” may refer to, for example andwithout limitation, personal computers, mobile phones, internet kiosks,embedded processors, gaming systems, other types of computing systemscapable of being used by a user to access content on a network, and soforth.

A browser 121 typically maintains or includes a URI history 122, acookie repository 123, and a page display 124. The term “browser” isused broadly and may refer to, for example and without limitation,applications like Internet Explorer, Opera, Firefox, Lynx, as well asembedded browsers, branded browsers, and “headless” internet processors,web crawlers and spiders, and other programs or applications that arecapable of formatting network content for consumption.

A URI history 122 contains a listing of at least some of the URIsrecently visited or rendered by the browser 122. A URI history may bestored in RAM, non-volatile memory, a database, a flat file, or somecombination thereof URI history entries may be set, deleted, or modifiedthrough the typical mechanisms provided by particular storage medium.Entries may be stored as plain text, XML, encrypted, and/or obfuscated.A browser 122 may occasionally clear or reset entries in the URI history122, and a browser 122 need not necessarily add all visited URIs to thehistory 122. The URI history is typically used to allow the browser 121to provide the user 122 with an indication of which web pages have beenpreviously visited. One such indication is to highlight previouslyvisited links with a different color than non-visited links.

A cookie repository 123 contains cookies 140 set by web servers accessedby the browser. Cookies are name-value pairs associated with aparticular domain, and are commonly stored on the user computing device120 with associated cookie attribute data. When a browser sends a URIrequest to a web server, it may include in the request one or morecookies corresponding to the URI's domain.

A web page 124 is the result of the browser's 121 processing, execution,and/or display of web code received in responses from web sites 101-03.Web page code need not be displayed or rendered as a web page in orderto have its executable sections, if any, executed. Browsers willtypically provide facilities for execution of types of executable webcode such as JavaScript 125. A variety of additional client sidescripting or programming languages likely to be supported by a givenbrowser 121 include, but are not limited to, Java applets, FlashActionScript, a customer browser plug-in or an installed piece of codeon the user's computer.

JavaScript, herein illustrated as a JavaScript section of the web page124, refers in particular to the scripting language often used forclient-side web development. A section of JavaScript code 125 istypically executed by the browser 121 within a “sandbox”, i.e. withlimited privileges to the user machine and browser's underlying datastructures and methods. One such typical privilege limitation isrestricted access to the URI history and cookie repository. One of skillin the art will recognize that some embodiments of the invention willuse mechanisms other than JavaScript to query the URI history. Amongothers, client-side code in nearly any language supported by the browser121 (such as those described above) that supports functionality similarto that of the JavaScript described below may work.

A particular web site 103 may be comprised of a web server 104, asetting service 105, a testing service 106, and/or a database 107, eachof which may be implemented on one or more physical servers or machines.The use of the word “service” is meant broadly and without limitation,and is used generally to refer to a collection of computer-implementedfunctionality. Neither the testing service nor the setting service needbe distinct or separable components of a computer system and they neednot be distinct from the web server 104 or any other element of the website 103.

The web server 104 typically receives requests over the Internet 100from user computing device 120. The web server 104 typically responds tosuch requests with a web page containing (without limitation) HTML code,JavaScript code, widget code, applet code, style sheets, XML, XHTML,AJAX, and/or other content (all of which is hereinafter referred to as“web code.”) The web server 104 may query the setting service 105 and/orthe testing service 106 for web code appropriate to save or retrievestate to/from the URI history 122 of the requesting browser 121.

The setting service 105 typically responds to a query by the web server104 with web code appropriate to cause the creation of entries in abrowser's URI history 122 when the code is loaded, rendered, or executedon the user's computing device 120. The setting service 105 may access adatabase 107 to retrieve or store information regarding the knownpreferences or attributes of a user 120. The setting service 105 isoptional in the sense that a user's URI history 122 will typicallyautomatically store visited URIs 130, 134-136 in the history. As such, asetting service may be most useful if a web site 103 intends to storecomplex values or state in a user's history 122.

The testing service 106 typically responds to a query by the web server104 with web code appropriate to take action based on the existence ofone or more entries in a browser's URI history 122 when the code isexecuted on the user's computing device 120. The testing service 105 mayaccess a database 107 to retrieve or store information regarding theknown user preferences or attributes associated with a user computingdevice 120.

3. SYSTEM OPERATION

With reference to FIG. 1, one illustrative use of one embodiment of thesystem will now be described. Broadly speaking, this example willillustrate how the system may be used to store the user's preferredopt-out policy across HTTP sessions without requiring the user to signin, use cookies, or maintain the same IP address.

At the direction of a user, the computing device 120/browser 121 makesan initial request to the home page of Site3 103, viz. site3.com. Such arequest is typically initiated by a user by typing a web page addressinto the location bar of a client browser 121, selecting a bookmark inthe browser 121, or by selecting a hyperlink displayed in the page area124 of the browser 121, although other mechanisms of initiating arequest are possible. The browser then typically transforms the user'srequest into an encoding appropriate for machine communication andtransmission. This request may be through the HTTP or HTTPS protocols,or generally through any protocol for which clients are capable ofexecuting client-side code and recording accessed locations. In the caseof HTTP and HTTPS, requests include a Uniform Resource Identifier (URI),which is a unique identifier that describes the location of a particularresource. Examples of URIs include http://www.ietf.org/rfc/rfc2396.txt,news:comp.infosystems.www.servers.unix, and telnet://192.0.2.16:80/.URIs are described in detail in Request For Comment 3986, available athttp://tools.ietf.org/html/rfc3986, which is hereby incorporated byreference in its entirety. Requests may include additional information,as defined by the relevant protocol, including cookies, etc.

Requests emanating from the user's browser 121 are routed through theuser's computing device 120, and thereafter through the internet 100,or, more generally, any type of communications network, to Site3's webserver 104. Some embodiments of internet routing are described inRequests For Comment 791 and 793, available athttp://tools.ietf.org/html/rfc791 and http://tools.ietf.org/html/rfc793,respectively, both of which are hereby incorporated by reference intheir entirety.

Upon receipt of a request, typically the web server 104 will attempt tofulfill the request by provisioning and returning content to the user120. Often, the content to be returned to the user 120 will be dependentupon information contained in the request (such as cookie data) and oninformation contained in Site3's general data repositories (not shown,but such as user authentication information, user preferences, pastbrowsing history, and so forth). Content may include text, images,movies, executable code, stylistic elements, tags, hyperlinks, andnumerous other types of data.

The content will typically be returned to the user's computing device120, whereupon it is typically rendered, executed, and/or displayed bythe browser as a page 124. Browsers will also typically create an entryin a URI history 122 corresponding to the fulfilled request, hereSite3.com. The exact mechanism of creating such an entry variesaccording to the type of browser 121 being used. One of skill in the artwill recognize, however, that browser history entries are typicallycreated upon successful fulfillment (or, possibly, initiation) of arequest. Entries may be pruned from the URI history if a given entry isnot revisited in a period of time, if a given entry is not within thetop N most recently accessed entries, through another algorithm, or somecombination thereof. Here, for example, after receiving content insatisfaction of the request for content at URI http://site3.com, theuser's browser 121 may create an entry in its history 122 for Site3.com,e.g. the entry referenced at label 134. One of skill in the art willrecognize that “surfing” a web site, i.e. requesting a first page, thenclicking on a link to a second page from the first page, then clickingon a link to a third page from the second page, and so forth, willtypically tend to create a sequence or trail of entries in the URIhistory 122, such as that illustrated by references labels 134-36. So,for example, the user may navigate from Site3's home page (site3.com) toview Site3's privacy policy and opt-out page, site3.com/privacy/.

Additionally, in fulfilling a request, the web server may access theoptional setting service 105. The setting service may be implemented asa collection of data, objects, or methods, or parts of data, objects, ormethods, located on one or more servers, that provides URIs fortransmission to browsers, where the URIs are used to store stateinformation. So, for example, when a given user requests Site3's privacypolicy page, site3.com/privacy, the setting service may include as partof the content of site3.com/privacy a special URI for transmission tothe user. This URI may such that, if placed in the user's URI history,the URI will indicate that the user wishes to confirm that they want toopt out of Site3's user tracking mechanisms. The URI could behttp://site3.com/opt-out and could be transmitted to the user as an HTTPanchor tag in the content of site3.com/privacy, e.g. “<ahref=“http://site3.com/opt-out”>Click here to confirm your desire toopt-out</a>”. This content may be returned by the setting service 105 tothe web server 104, and the web server may include this URI content aspart of its complete response to the user's request forsite3.com/privacy. The testing service may access a database 107 tostore, retrieve, or determine information appropriate to the URI. Forinstance, the testing service may cause an entry to be stored in thedatabase 107, where the entry connotes that the URIhttp://site3.com/opt-out indicates that a user does not wish to betracked.

As discussed above, once the browser 121 receives the response content,it will typically be displayed in the browser's page display area 124.If the user clicks on the link containing the special URI, it will causea request to be made to the confirmatory URI (http://site3.com/opt-out)and cause an entry to be created in the user's browser's URI history122, such as that shown at reference label 136. The actual content ofthe page at site3.com/opt-out may consist simply of the text “Thank youfor opting out” or may be more or less extensive. It may contain linksfor the user to return to the home page of the web site. Of course, itis not necessary that the user be presented with an explicit anchor tagproviding a link to a URI which serves as the opt out URI, nor is itnecessary that the user click on a link or be notified that clicking onthe link serves to cause storage of state information in the URI history122.

Assuming that the user returns to Site3's home page after confirming thedesire to opt out, the user may then subsequently browse to other pagesin Site3's domain, such as shopping pages (site3.com/shopping), productreview pages (site3.com/view/widget1039), etc. At each of these pages,and, in general, at any of Site3's pages, the Site3 web server 104 mayinclude logic for tracking or monitoring the user's behavior. Forexample, the web server may typically maintain a history of all of theproducts viewed by a user. This history may be displayed to the user ascontent in the form of “Here are the last 7 products you viewed here atSite3.com . . . ” Mechanisms for tracking user behavior are well-knownin the art.

Before conducting tracking operations on a particular user, the webserver 104 may determine whether the user has opted out of tracking. Todo so, the web server may first poll the testing service 106. Thetesting service may be implemented as a collection of data, objects, ormethods, or parts of data, objects, or methods, located on one or moreservers, that provides code for inclusion as content of a requestedwebpage, where the code may be used to read state information out of theURI history 122 of the browser. So, in this case, the code may consistof a section of JavaScript, such as the JavaScript illustrated in Table1, that, when executed, checks to see whether the user has visitedsite3.com/opt-out, and reports the results of this check to the webserver 104. If the user has visited that URI, then the code section (andalso the system, if the code section reported the results of the test)knows that the user has opted out of tracking. Returning to FIG. 1, thetesting service may utilize the database 107 to store, retrieve, ordetermine information appropriate to checking for a URI. In this case,the testing service 106 may retrieve the entry regardingsite3.com/opt-out originally placed in the database by the settingservice 105.

TABLE 1 A pseudocode listing illustrating the use of entries in the URIhistory in accordance with some embodiments of the invention. 1:  mylink= createNewAnchorLink(http://www.opt-out.com); 2: addElementToDocumentObjectModel(mylink); 3:  computedLinkColor =getComputedLinkColor(mylink); 4: removeElementFromDocumentObjectModel(mylink); 5:  if (computedLinkColor= VISITED_COLOR) { 6:  RedirectTo(“http://server1.com/products?optout=yes”); 7:  } else { 8:  RedirectTo(“http://server1.com/products?optout=no”); 9:  }

The testing service 106 may return to the web server 104 a section ofexecutable web code 125 adapted to be transferred to and executed on theuser's browser 121. The web server will typically return the section ofexecutable code to the user as part of the content of a complete webcode response to the user's original request.

Once received by the user's computing device and browser 121, thebrowser may attempt to render the content in a content display area 124.Part of the rendering process may include executing code 125 included aspart of the content. In this example, the user's browser may executecode 125 analogous to the pseudocode shown in Table 1. If the particularURI is present in the URI history, execution of a JavaScript codesection 125 implementing the pseudocode of Table 1 may cause thatinformation to be sent to the Site3 web server 104 as part of anadditional request. In this case, the JavaScript 125 may detect theexistence of the opt-out URI in the user's history 122 (Table 1, lines1-5) and thereafter cause a redirect, e.g., a window.location( ) methodcall, to transmit that information to the web server 104 and load newcontent. (Table 1, lines 6 and 8.) Alternatively to causing anadditional request, the JavaScript may set the value of a particularname-value pair if the opt-out URI is detected. This name-value pair maythen be transmitted to the server 104 as part of a typicaluser-initiated submission of a web form.

The executable code may also or alternatively perform other types ofprocessing based on the URI or URIs found in the history 122. Thesesteps could include, but are not limited to, notifying the user, causingthe browser to request a URI that is dependent upon the outcome of theURI check, causing a hidden display object to become visible on the page124, deleting information in accordance with the user's privacysettings, and so forth. The executable code 125 may be adapted toperform some action, including reporting to the server, if theparticular tested-for URI is not present in the URI history 122.

If the server receives notification from the executable code, eitherthrough a redirect, request, submission of a name-value pair, or othermechanism, that the user has chosen to opt-out or opt-in, the server mayimplement the user's particular opt-out privacy wishes. This mayinvolve, for example and without limitation, any of the following: (1)not including tracking widgets (as known in the art) in subsequentrequests by the user; (2) deleting data or disabling functionality onthe web server with respect to the user; and/or (3) disablingfunctionality, such as tracking functionality, on the user's computingdevice (in accordance with the user's preferred opt-out choice).

Those of skill in the art will recognize that the foregoing process ofenforcing the user's opt-out choice does not require (but is compatiblewith) the use of session histories, caches, cookies, execution of aprivileged applet, or other usual mechanisms for maintaining state. Onthe other hand, the foregoing process may be used in combination withthe above-mentioned mechanisms. For example, upon detecting that aparticular URI is in the URI history, the executable code 125 executingon the user computing device 120 may cause a cookie 140 to be created inthe cookie repository 123.

It will be recognized that the setting service 105, as described, isoptional. Some embodiments may be practiced without a setting service.In some of these embodiments, the URIs of particular visited web pagesmay still be stored in the browser's URI history 122, and the testingservice 106 or web server 104 may maintain a record of which URIscorrespond to which elements of state.

Additional processing, in lieu of or in addition to that describedabove, may be performed by the executable code 125. This may includedeleting information according to the user's privacy settings (such ascookies), notifying the user (such as a notification that the privacypolicy is being respected), redirecting to or causing the browser torequest another page, requesting additional content from a server fordisplay on the page, and/or modifying an element displayed on the page.In general, any type of action consistent with the expressive power ofthe executable code (and the privileges afforded to the code by thebrowser) may be performed.

TABLE 2 A code listing illustrating an example of a section of CSSsemantics that makes use of entries in the URI history in accordancewith some embodiments of the invention. <style>  #link1 a:visited { background:url(log.cgi?ip=76.247.104.87&date=2008-04-13&uri=opt-out.com&visited=1);  }  #link1 a {   background:url(log.cgi?ip=76.247.104.87&date=2008-04-13&uri=opt-out.com&visited=0);  } </style> <div id=“link1”>  <ahref=“http://opt-out.com/”>   opt-out.com  </a> </div>

It will also be recognized that the use of JavaScript is merely onemechanism for reading the URI history and taking action upon thathistory. Other methods include but are not limited to (1) conditionalimage loading as described at http://ha.ckers.org/weird/CSS-history.cgi,last visited Apr. 5, 2008, (2) browser applets and plugins, and (3)Java. An illustration of the use of CSS to infer the existence ofobjects is provided in Table 2. Those of skill in the art will recognizethat the“background:url(log.cgi?ip=76.247.104.87&date=2008-04-13&uri=opt-out.com&visited=1)”line in CSS is rendered (and thus the log.cgi web resource is accessed)if the particular URI corresponding to the enclosing anchor tag, hereopt-out.com is marked as “visited” (i.e. present in the URI history) bythe browser. Similarly, the“background:url(log.cgi?ip=76.247.104.87&date=2008-04-13&uri=opt-out.com&visited=0)”is rendered if the test URI (opt-out.com) has not been visited.

4. EXAMPLE USE CASES

Cross-Domain Opt-Outs

FIG. 2 illustrates an embodiment in accordance with cross-domain URIhistory detection and processing based thereon. Client 201 may be auser's computing device and browser or any device capable ofcommunicating on a network. Service Provider A illustrates a web serviceprovider acting as a generalized privacy policy provider. Web servicesgenerally include the provisioning of HTML pages, WL pages, RSS feeds,or generally any resource capable of transmission across a network.Service Provider B illustrates another web service provider, whereinService Provider B is a provider that may normally be in a position toenforce or respond to privacy policy choices. Such providers includeretail web sites, news sites, RSS feed syndicates, and so forth. Forthis example, Service Provider B is assumed to be on a differentInternet domain (although the example still works for providers on thesame domain). For purposes of the illustration shown in FIG. 2, ServiceProvider A and Service Provider B are automated computer systems orsites operated by different respective business entities.

Presume for the sake of the example that the client 201 has navigatedthrough pages provided by Service Provider A and is now presented withthe option of clicking on a text link or other hyperlinked displayobject to confirm the client's acceptance of a particular opt-outpolicy. Such a link may have a target URI such ashttp://spA.com/opt-out. A page displaying confirmation of the client'sacceptance may be located at the URI. Of course, Service Provider A mayprovide additional opt-in and/or opt-out pages, and perhaps some ofthese may represent privacy choices specific to certain web sites orcertain privacy actions. So, for example, such a page may have a URIsuch as http://spA.com/opt-in (for someone who explicitly agrees to alltracking) or http://spA.com/opt-out-class3 (where class 3 representssome admixture of privacy options.) Of course, Service Provider A's ownroot page (spA.com) may itself correspond to some selection of privacychoices by the user.

At 210, the client 201 makes a request to Service Provider 1 202 for oneof the URIs discussed above. For the sake of generality, this URI willbe referred to as “URI1”. At 211, the service provider returns aresponse including web code to the client 201. This particular responsemay or may not include executable code. At 212, the client browser 201renders the web page code and may subsequently place (or have previouslyplaced) URI1 into the history.

At a subsequent time, as illustrated at 213, the client 201 may requesta web page from Service Provider B. At 214, the Service Provider B willtypically return web page code. In this example, the web page codeincludes a URI checking mechanism (here illustrated as JavaScript) thatmay be designed to check for the existence of URI1 (which, as the readerwill recall, is a URI from Service Provider A) and then performadditional processing based on whether URI1 is detected. The JavaScriptmay be designed to test for multiple URIs, and may be designed to checkfor particular URIs based on some specific attribute of the requestinguser (such as a user name, an IP address, and so forth).

The client browser 210 receives the web page code including the URIchecking mechanism and, at 215, executes the JavaScript. At 216, theJavaScript checks for the existence of URI1 in the client's history. At217, the JavaScript performs additional processing based on detection ofthe URI1. This additional processing may include requesting new contentfor the user; varying a parameter of a content request to cause aparticular type of content to be displayed or omitted; declining torequest particular content that would otherwise be displayed to theuser; expanding the amount of data collected or retained from the user;exposing hidden information on the page; contracting the amount of datacollected or retained from the user; scrambling, encrypting, orotherwise obfuscating the user's data or attributes; reconciling theuser's URI history with the user's cookies or cache; confirming with theuser that he or she wished to opt out; or generally any action thateither should or should not be performed based on a state attribute ofthe user.

In this example, the additional processing may comprise sending databack to Service Provider B which indicates that the user has selectedthe given privacy policy at Service Provider A. Service Provider B maythen choose to alter its data retention policy with respect tointeractions with this user to conform to the user's privacy policy.Service Provider B may also choose to set, modify, or delete cookies (orname-value pairs) to record the privacy policy of the user. For example,Service Provider B may create a cookie, similar to that illustrated atFIG. 1, 140, which is consistent with the detected global opt-out URI.On the other hand, Service Provider B may create a cookie whichoverrides the global opt-out URI.

Differential Content Selection

FIG. 3 illustrates an embodiment in accordance with maintenance of userstate information. At 301, the server receives a page request from auser. At 302, the server responds with a transfer of code to be loadedor executed by the user. Typically this code will include a mechanismfor checking the existence of items in the URI history of the user'sbrowser. At 303, the code is loaded or executed on the user's browserand computing device.

In this example, assume that the code is testing for the existence of aURI which indicates that the user has viewed a “Fire Sale! 20% OffEverything” page. This URI may be https://merchant.com/firesale.html. At304, the code tests for the fire sale URI. If the URI is found in theuser's history, the code may cause a transmission to the merchant toindicate that fact. Alternatively, if the URI is not found, the code maycause a transmission to indicate that fact as well.

In this example, assuming that the URI was found in the history (Block305), the code may explicitly make a particular redirection request tothe server. Here, the code may cause a request for the web page at URIlocation http://merchant.com/products?salepercent=20. Alternatively, atblock 306, assuming that the URI was not found in the history, the codemay explicitly make a request for a different URI location, such ashttp://merchant.com/products?salepercent=10. In this way, the system isable to differentiate seamlessly among users who have visited differentsets of pages and to provide different content to those differentusers-without reliance upon cookies or caches.

Affiliate Tracking and Commissions

Web merchants often use affiliates, wherein the affiliates receive acommission in exchange for directing traffic to merchant web sites. Thiscommission may be payable when a particular user clicks on a link fromthe affiliate's web site to the merchant site, or the commission mayonly be payable if the particular user subsequently purchases the itemto which the user is directed.

The merchant's system may implement affiliate tracking by checking forURIs of affiliates or products of affiliates in user URI histories. So,for example, if a user purchases a particular grill from a merchant, themerchant's system may transfer web code to the user to check if the URIhistory of the user contains an affiliate's product page. In otherwords, if affiliate.com/grill.html links to merchant.com/grill.html,then the merchant's system may (using the methods disclosed above) checkfor the existence of affiliate.com/grill.html in the URI history. Themerchant system may check for multiple affiliates and, in case a userhas visited multiple appropriate pages, the merchant may arbitrate theconflict. The conflict may be resolves by splitting the commission amongthe affiliates.

This system may be used concurrently with a cookie- or session-basedapproach.

Generalized State Storage

The disclosed processes may also be used to store generalized, multi-bitstate data. The setting service 105 may cause a user's browser to bedirected or redirected to multiple URIs, each of which encodes a pieceof information (which may be less than, equal to, or greater than onebit of information). The URIs that form the state data may be explicitlylinked together (such as site.com/bit1, site.com/bit2, etc.) or they maybe encrypted, obfuscated, or otherwise non-obvious. They may encodestate in binary (as shown below) or in other some other base. Thecontent at the particular URIs may be special purpose (presumably likesite.com/bit1) or they may themselves serve useful purposes outside ofstoring state (such the site.com/opt-out examples demonstrated earlier).

The setting of multiple URIs may be accomplished with the help of theuser (such as by asking the user to click on multiple links) or may beaccomplished automatically (such as by causing multiple re-directs). Ingeneral, methods for causing loading of or redirecting to a chain or setof multiple web pages are well-known in the art and may be appropriatefor causing storage of multiple URIs in the history. It is possible,however, that not all browsers support all methods for loading orstoring multiple pages.

To illustrate the example of storing generalized state, to store thevalue 6 (0110 in binary), the system or setting service could cause theloading of 2 distinct pages: site1.bit2 and site2.bit1. (The reader willrecall that 6=2²+2¹.) To retrieve the encoded state in subsequentrequest, a section of JavaScript may be executed. The section may checkfor the existence of site.com.bit,*, where * varies from 0 (representing2⁰=1) to 3 (representing 2³=8). In this example, the JavaScript willdetect bit1 and bit2 and thus reconstruct 2+4=6.

The number or identifier thus reconstructed, along with otherinformation known about the request or the user, may be used toreference a record stored by the server. This record may contain furtherinformation about the user, such as preferences, demographic groups,etc.

Prevention of Deep-Linking

One problem often encountered by web providers is that of “deep linking”wherein third parties serve links to pages “deep” within a web site(such as photographystore.com/pictures/image20394.html). This type oflinking may frustrate the intentions of the web provider if, forexample, the web provider would prefer that visitors see the site's homepage (e.g. photographystore.com/welcome) before viewing content. Thisproblem is especially acute, for example, with news providers (such ascnn.com) whose stories may be deep-linked by web search providers.Deep-linking can be a source of litigation.

Some embodiments of the present invention may alleviate deep-linking asfollows: When serving a response to a content request by a user,especially a request that includes a HTTP-Referrer string that points toa 3^(rd-)party site, the web service may include a section of web codethat uses the URI history to determine whether the user has previouslyvisited the home page of the service provider. If not, the web code maycategorize the user's access as one of deep linking (since the user hasvisited an inner link without first visiting the home page). The webcode may thereafter cause the user to be redirected to the home page.Alternatively, the web code may cause the page displayed to the user tobe modified in some way, perhaps by causing a popover or similar to bedisplayed on the user's browser.

Variant State

Typical browsers may not afford JavaScript (or other mechanisms foraccessing URI histories as discussed above) sufficient privileges toremove or modify URI entries. Some embodiments of the present inventionmay overcome this write-once limitation by providing a mechanism formarking URIs in the history as outdated or invalidated. Some embodimentsmay store “epoch counter” URIs in the history, so as to allow “stale”URIs in the history to be ignored. The broad idea behind epoch countingis that once a new epoch has started (e.g. Epoch 3), items marked withprevious epochs (e.g. Epochs 0, 1, and 2) are invalidated.

As an example, suppose that a system wishes to record the opt-out oropt-in preferences of its users in a URI history and, moreover, wants toallow users to modify their preferences over time. In order to read theuser's current preference, the system may transmit JavaScript or otherhistory-checking code to the user that first checks a sequence of epochURIs. Some embodiments of the invention may therefore first check tofind the current epoch and subsequently invalidate (or otherwisedeprecate) URIs corresponding to previous epochs.

So, for example, the JavaScript may first check for URIsite4.com/privacy_epoch0. If this URI does not exist, the system knowsthat the user has not set privacy preferences (or has recently had themremoved or expired from the URI history). If, however,site4.com/privacy_epoch0 exists, the system may check forsite4.com/privacy_epoch1. If epoch 1 does not exist, the system knowsthat the current epoch is 0. If, however, site4.com/privacy_epoch1exists, the system may check for site4.com/privacy_epoch2. If epoch 2does not exist, the system knows that the current epoch is 1. If,however, site4.com/privacy_epoch2 exists, the system may check forsite4.com/privacy_epoch3, and so on. Eventually, the system may find thelast epoch that has a corresponding URI entry—this will be the currentepoch.

The system may then use this current epoch as a key for referencing theactual state value in the URI history. For example, if the current epochis 2, then the system may look for site4.com/privacy_epoch2 opt-in,site4.com/privacy_epoch2 opt-out, site4.com/privacy_epoch2 bit1, and soforth and as described above. The system may ignore any state valuesassociated with expired epochs. (Such assite4.com/privacy_epoch1_opt-in.)

In order to store or modify state values, the system may first determinethe current epoch (using a mechanism like that discussed above) and anyrelevant state values. The system may then present the user with linkscontaining specially crafted URIs that increment the epoch counter andset the new value. So, for example, if the system detects that thecurrent epoch is 17, the setting service and web server may transmit webcode to the user's browser that causes a URI or URIs representing bothan incremented epoch counter (such as site3.com/privacy_epoch18) and anew state value (site.com/privacy_epoch18 opt-in) to be stored in thehistory. Example mechanisms for storing multiple URIs are discussedabove.

Separate epoch counters (such as site4.com/privacy_epoch2), representedas distinct URIs, are not necessary. Some embodiments may scan throughpossible state values to determine the one with the highest implicitepoch number. For example, a system may start by checking for valueswith epoch=0, such as site5.com/opt-in_(—)0 and site5.com/opt-out_(—)0.Presumably, only one of these will exist (otherwise they would indicateinconsistent state). If either of these are found, the system may scanfor values with epoch=1, such as site5.com/opt-in_(—)1 andsite5.com/opt-out_(—)1. If nothing under epoch 1 is found, then thesystem knows the value or values it found under epoch 0 are current. If,however, something is found under epoch 1, then the system will scan forvalues under epoch 2, and repeat the process. Eventually, a set ofvalues with an epoch number not exceeded by any other value will befound. In some embodiments, these will be the current values.

Of course, mechanisms other than epochs may be used, including (withoutlimitation) timestamps, datestamps, hashed values, and/or other statevalues encoded as described above under “Generalized State Storage.”

5. CONCLUSION

All of the methods and processes described above may be embodied in, andfully automated via, software code modules executed by one or moregeneral purpose computers or processors. The code modules may be storedon any type of computer-readable medium or other computer storagedevice.

Although this invention has been described in terms of certainembodiments and applications, other embodiments and applications thatare apparent to those of ordinary skill in the art, includingembodiments and applications which do not provide all of the featuresand advantages set forth herein, are also within the scope of thisinvention. Accordingly, the scope of the present invention is intendedto be defined only by reference to the claims.

1. A computer-implemented method, comprising: determining, via browserexecution of code on a user computing device, that a particular UniformResource Identifier (URI) is included in a browser's URI history storedon the user computing device, said particular URI representing a userpreference setting; and in response to determining that the particularURI is included in the browser's URI history, causing the user computingdevice to generate a request for content corresponding to the userpreference setting.
 2. The method of claim 1, wherein the userpreference setting is an opt-out setting.
 3. The method of claim 2,wherein the opt-out setting applies to multiple different web sites,each of which is operated by a different respective entity in adifferent respective Internet domain.
 4. The method of claim 1, whereinthe URI is stored in the URI history as a result of a user selectionaction performed on a web page of a first web site in a first domain,and the method is performed via execution of code of a web page loadedby the browser from a second web site in a second domain.
 5. The methodof claim 1, wherein the code comprises JavaScript.
 6. The method ofclaim 1, wherein the code conforms to Cascading Style Sheet semantics.7. The method of claim 1, wherein the code comprises a Java applet.
 8. Acomputer storage system having stored thereon a browser-executable codesequence that embodies the method of claim
 1. 9. A web server systemoperative to serve a web page that includes browser-executable code thatembodies the method of claim
 1. 10. A system, comprising: a server thatprovides access to at least one web page that provides a user option toselect a content preference; a setting service that is responsive touser selection of said content preference by causing a URI representingthe selected content preference to be incorporated into a browserhistory stored on a user computer; and a testing service that isresponsive to a page request from said user computer by returning abrowser-executable code sequence that causes the user computer to checkfor the URI in said browser history.
 11. A computer-implemented method,comprising: receiving a page request from a user computing device; andresponding to the page request by returning a web page that includes abrowser-executable code sequence that check a browser history stored onthe user computing device for a particular URI that represents a userpreference setting, and that causes the browser to request content thatcorresponds to said user preference setting.
 12. A method for servingweb content, comprising: receiving a request from a user's computingdevice including a URI history; providing, in response to the request,content comprising code configured to be rendered or executed on thecomputing device and thereby to cause a transmission to a computingdevice based on at least one access to the URI history.
 13. The methodof claim 12, further comprising providing a second response to theuser's computing device, the second response being a response to thetransmission, wherein the content of the second response varies as afunction of the transmission.
 14. The method of claim 12, furthercomprising providing a second response to a second request by the user,wherein the second response varies as a function of the transmission.15. The method of claim 12, further comprising providing services to theuser's computing device that vary as a function of the transmission. 16.The method of claim 12, further comprising adjusting the amount ofinformation retained about the user based upon the transmission.
 17. Themethod of claim 12, wherein the code comprises JavaScript.
 18. Themethod of claim 12, wherein the code conforms to Cascading Style Sheetsemantics.
 19. The method of claim 12, wherein the code comprises a Javaapplet.
 20. A system for maintaining user state, comprising: a webserver; a setting service; and a testing service; wherein the web serveris configured to respond to requests for content by a user's computingdevice with content from the setting service and the testing service;the setting service is configured to provide a sequence of at least oneURI to which the user's computing device will be redirected or linked,the URI containing information representative of a state valueassociated with the user; and the testing service is adapted to providecode configured to be rendered or executed on the computing device andthereby to perform an action based on at least one access to a URIhistory of the user's computing device.
 21. A system for maintaininguser state, comprising a web server configured to respond to a requestby a user's computing device with content including code configured tobe rendered or executed on the computing device and thereby todifferentiate among entries in a URI history of the user's computingdevice, wherein the entries contain epoch counters and the code isconfigured to use the epoch numbers to differentiate the entries.
 22. Acomputer-implemented method, comprising: determining, via browserexecution of code on a user computing device, that a particular resourceis included in a repository of a browser, the repository stored on theuser computing device and the resource representing a user preferencesetting; and in response to determining that the particular resource isincluded in the repository, causing the user computing device togenerate a request for content corresponding to the user preferencesetting.
 23. The method of claim 22, where the repository stores recordsof prior user actions.